The present invention generally relates to configurable data processing systems. Particularly, the present invention relates to a method, a system, and a computer program product for reconfiguring functional capabilities in a data processing system with dormant resources.
A computer system may comprise multiple similar or identical hardware units providing the same type of resources, for example memory cards, multi-chip processor modules, input/output cards with multiple ports, etc. A hardware unit itself can be composed of multiple components; e.g. a processor book can be comprised of a multi-chip processor module and an amount of memory, where the multi-chip processor module contains a number of processors, and a computer system can contain more than one of these processor books. The hardware units are typically field-replaceable, which means they can be replaced by a field engineer at the customer location.
For various reasons, the hardware units may not be used to full physical capacity but by some firmware supported control mechanisms, the exploitation may be limited. For example, only 3 of 12 physical processors contained in a multi-chip processor module may be enabled for execution. The unused resources are called dormant resources. This has various advantages, e.g., that the capacity of a computer system can be changed dynamically based on performance or other needs.
Another advantage is granularity: Dormant resources allow offering a wide range of system configurations without the need to reflect every configuration physically. Multiple models, variations and capabilities of modern computers represent a wide variety of choices to the consumer; the concomitant requirement that multiple variations and models of such computers be manufactured and stocked would represent a substantial burden to computer manufacturers.
For example, it is too expensive to build a specific multi-chip processor configuration for every number of processors that can potentially be used. Each existing model, variable functional characteristic or capability of a computer system represents a large number of different systems, subassemblies and components, which must be manufactured and stocked to maintain customer satisfaction.
The International Patent Application PCT/EP03/13073 teaches a method and system for alternatively activating a replaceable hardware unit in a data processing system. Initially a replaceable hardware unit is added to the data processing system, and then its type is determined. If the replaceable hardware unit is of a first type, a subset of its functional capabilities to be electronically enabled is determined. Alternatively, if the replaceable hardware unit is of another type, the entire functional capabilities of the replaceable hardware unit are enabled. The method allows solving compatibility issues for hardware units when they are used in very different models or configurations of a data processing system. For models or configurations that do not all allow to use the entire set of capabilities of a hardware unit, a subset of the functional capabilities is enabled only.
The U.S. patent application 2003/0120914A1 describes a method and system for flexible temporary capacity upgrade/downgrade in a computer system without the involvement of the operating system. Dormant resources are used to upgrade the capacity of the computer system. Capacity is downgraded by disabling used resources, which then become dormant resources. The usage of this method for the IBM® eServer® z900 is described in J. Probst et. al.: “Flexible configuration and concurrent upgrade for the IBM eServer z900”, IBM J. Res. & Dev., Vol. 46, No. 4/5, 2002.
Both state of the art methods use the vital product data (VPD) of a computer system that among other things describes the separate hardware units contained in the computer system. Especially, the VPD describes if a hardware unit is used or not, hence if it is a dormant resource or not. This subset of the VPD is called enablement definition data. Typically, the system VPD is composed of the VPD of its various hardware units. The VPD including the enablement definition data of a hardware unit is stored in a device that is part of the respective hardware unit, e.g. in a serial electrically erasable programmable read only memory (SEEPROM) or in a smart chip.
In order to ensure the integrity of the VPD, especially the enablement definition data, and to prevent against tampering and misuse, secure protection mechanisms store an encrypted version of the enablement definition data in the hardware unit. The encrypted version of the enablement definition data is then decrypted by the system firmware when it is read from the hardware unit. The U.S. Pat. No. 5,982,899 describes such a mechanism. It uses an intrinsic and unchangeable identifier incorporated in a chip on each hardware unit and a non-symmetric encryption method with a private/public key pair to prevent counterfeiting and protect the VPD against misuse.
The unchangeable identifier is specific to that certain chip. Such an identifier is typically based on the electronic chip identifier provided as a standard service by modern CMOS fabrication technology. The identifier is used to encode the VPD. This encoding links the VPD to the specific hardware unit and prevents the cloning of the VPD of other samples of the same hardware unit. To prevent manipulation, the encoded VPD is encrypted with a private key known only to the restricted manufacturing process of the hardware unit.
The system VPD is aggregated by the system firmware during the system power-on phase by collecting all the VPD from its various hardware units. It is possible that the system VPD is managed and stored with the help and/or on a separate service processor or service console. Based on the enablement definition data in the system VPD, the available hardware capacity of the computer system is determined.
The enablement definition data of a hardware unit can also be overwritten in the system VPD. It is possible to associate an expiration date to the enablement definition data that is used to overwrite the enablement definition data of a hardware unit in the system VPD. This allows temporary upgrades of the computer system, which are revoked when the expiration date is reached.
During system runtime the VPD is updated by the system firmware whenever a new hardware unit is logically added to the system or logically removed from the system. However, a hardware unit is not logically removed from a system during its normal operation phase, when it is detected by some means that it is broken. It is only logically removed by a special remove operation that is usually triggered separately by a system operator. When it is logically removed, then it will usually also be physically removed from the system. On the other hand, a hardware unit can be logically added to a system (in a special add operation) only, when it was physically added to the system before.
If a broken hardware unit is detected, then the entire broken hardware unit is disabled and fenced from the system by the system firmware. A hardware unit that is physically removed from the system without triggering a remove operation appears to the system as a broken hardware unit.
If a broken hardware unit is detected during the system power-on phase, then the enablement definition data of the broken hardware unit is not read and the available capacity of the system is determined according to the enablement definition data of the remaining hardware units only. This is a big difference to the case when the hardware unit breaks at system runtime because then the system VPD is completely built up already.
Until now it was not recognized that dormant resources introduced to simplify system configuration can also be used to compensate system degradation due to a broken hardware unit. Even if sufficient dormant resources would be available during the system power-on phase to replace the enabled resources of the broken hardware unit, current data processing systems will not use them and will not provide the same capacity as if the hardware unit would not be broken. Nor will current systems reduce the degradation of their capabilities when not enough dormant resources are available.